fix(cli): the metadata rubric records a linter crash instead of scoring it 100 / A - #15881

Contract review (clause ②) — PASS

Reviewed at head c4f2e7ae671b3e9044236cc4e79cc56f6eafbadd (merge-base with origin/main 59953d5a3). Posted as a COMMENT, not an approving review: GitHub refuses APPROVE on a PR authored under this same account, and agent seats do not submit approving reviews in any case. This is the in-seat contract review the card was dispatched under; the label stroke and landing are the seat's own and are not taken here.

Independence pair (C4):

• Implemented-by: branch claude/issue-15658-score-lint-crash-visible (subagent dev)
• Reviewed-by: session_01D47qPfEWVPmhguWgBZCi5N

Governed surfaces touched: none (.changeset/…, packages/cli/src/lint/score.ts, packages/cli/test/score-lint-crash.test.ts). metadata-eval.ts untouched, content/docs/releases/ untouched, no packages/spec/src/** file touched.

Clause ② — re-judged from the delivered diff, per limb

Mechanical limb — YES, and narrower than declared. packages/cli/src/index.ts re-exports commands only; score.ts is not on the package's . export and the exports map has no deep-import subpath ⇒ the mechanical limb's "new exported symbol on an index" leg does not apply, and the mechanical YES rests solely on the os lint --eval --json wire key. That key is real: driven through a dist built from this head, results[].score.lintError is an own property on every crashed case (5 of 5 lines on the crash run, 0 on the clean control), and the new rule value rubric/lint-crashed rides the same payload in results[].score.issues[]. LINT_CRASHED_RULE and MetadataScore are not npm-public TypeScript API. The packages/spec/src/** path leg is correctly declared not applicable.

Conformance limb — YES, re-derived. The input class is "a schema-valid stack on which lintConfig throws"; the concrete members are apps[].label and views[].list.label carrying an inline locale map. Same process, same input, OLD (merge-base) scorer vs NEW scorer:

The unchanged harness (metadata-eval.ts, passed reads counts.errors) fails the case at minScore 75 and at 0 (passed:false, ok:false, meanScore:0); the clean control passes at both. On the wire (os lint --eval --json --generator): crash generator EXIT=1, ok:false, 0/5 passed, meanScore 0; clean-generator control EXIT=0, ok:true, 5/5, meanScore 100. The wire-level before (exit 0) is derived, not driven by me: OLD scorer returns 100/A/valid:true with every count zero, passed (unchanged) is therefore true, ok true, and lint.ts exits 1 only on !report.ok — the dev's ablated-build table is taken on trust for that one row.

minor vs major — explicit verdict: minor is correct; not major; and no BREAKING banner or ADR-0087 disposition is owed

I did not take this from the green gate. The changeset gate checks the declaration's shape; the ADR-0087 gate is, by its own header, blind to omission — so "the gate confirms this declares no breaking change" is a tautology, not evidence. The ruling below stands on the merits.

1. The level axis. Under the maintainer's 2026-09-04 WHICH LEVEL ruling (pr-automation.yml, Check Changeset step) and the header of check-changeset-no-major.mjs, the bump level does not carry breaking-ness during the launch window: major is refused, and breaking-ness is carried by the BREAKING banner plus the ADR-0087 disposition. A new accepted key and a new accepted value on a published payload set the floor at minor, and a fix( type cannot lower it. minor is exactly what the ruling prescribes; major would be wrong on this axis regardless of the next question.
2. The breaking axis — is a BREAKING banner owed? No.
   • The repo's own definition (AGENTS.md rule 3): a breaking changeset "removes or renames anything an author can write (a spec key, an export, a config field)". This PR removes and renames nothing. Every existing key keeps its shape and meaning; the additions are optional and additive; a consumer that parsed the old payload parses the new one.
   • The behaviour flip is confined to an input class whose prior output was a defect against the rubric's documented contract — score.ts says a stack is good "exactly when it (a) parses and (b) is clean under the data-model lint rules"; a stack whose lint never ran was never established as (b). The 100 / A / exit 0 was unearned, not promised. Correcting an incorrect verdict for one input class is a fix, and this repo has twice shipped the same-family correction that way: #15576 and #15659 both flipped a published number from 100 to 0 on an input class and landed as patch with no banner.
   • The same input already failed the tool's primary face before this PR: os lint and os lint --score exit 1 on it, because the command-level lintConfig call (lint.ts:583) runs before scoreMetadata (:613). No consumer could hold a consistent green on this stack across the tool; only the eval face disagreed with the rest of it. Aligning it narrows no contract.
   • There is nothing to migrate: an ADR-0087 disposition presupposes an author-side rewrite, and an author who meets rubric/lint-crashed has hit a linter bug (#15880), not a metadata shape they must change.
   • What I do acknowledge: a CI that ran os lint --eval --generator against a generator emitting localized app or view labels goes from green to red. That is the correct verdict for that generator under the rubric and is the pass-flip #15658 was filed to close. It deserves plain words in the changeset body — which it has ("a stack half of whose rubric never ran came back as 100 / A") — not a banner whose meaning here is "you must rewrite something".

I18nLabelSchema — re-derived, admits the locale map

I18nLabelSchema = z.union([z.string(), InlineLocaleMapSchema]) (packages/spec/src/ui/i18n.zod.ts:247); InlineLocaleMapSchema = z.record(<key matching INLINE_LOCALE_KEY>, z.string()), and INLINE_LOCALE_KEY = /^(?!(?:key|defaultValue)$)(default|[A-Za-z]{2,3}(-[A-Za-z0-9]{2,8})*)$/ admits en and zh-CN. AppSchema.label: I18nLabelSchema (app.zod.ts:1291); ObjectStackDefinitionSchema.apps: z.array(AppSchema).optional() (stack.zod.ts:333). Executed at this head: safeParse success on apps[].label = { en, 'zh-CN' } and on views[].list.label = {…}; control on the schema axis: objects[].label is z.string() and the same parser rejects the map (objects.0.label: Invalid input: expected string, received object) — so the pass is not a parser that admits everything. Then lintConfig throws TypeError: Cannot read properties of undefined (reading 'toUpperCase') on both — checkLabelCase (commands/lint.ts:101-102) indexes label[0] on an object; control with a string label returns 0 issues and does not throw. Reachability (world i) is established; the "delete the catch" branch of the card is closed.

On the sweep's control. The 241 schema-INVALID crashers discriminate on the detector axis — they show the harness observes a throw from lintConfig at all, so "2 hits in 3,064" is not an always-zero detector. They do not discriminate on the filter axis (that "schema-valid" survivors really passed safeParse); that axis is covered by the objects[].label rejection, which I reproduced. The sweep's counts themselves are NOT MEASURED here (the sweep script is not in the PR); the card's question does not depend on them — one driven input settles reachability, and I reproduced both hits.

The three carriers — three readers, not three spellings

• Synthetic error issue — the only carrier the unchanged harness reads (passed ⇐ counts.errors === 0), the only one valid reads, and what the human --eval line prints (e.g. rule: message). Measured: at --eval-min 0 the case still fails only because of it.
• score: 0 / F — the only carrier meanScore reads (it sums score.score alone) and what the human per-case line prints; without it a crashed case contributes 100 to the mean, which re-opens #15659's exact defect. It is also the only content os lint --score --json publishes ({score, grade}, lint.ts:627) — on the current input class that face never reaches the scorer, but the scorer's contract is for any throw from any rule.
• lintError — the typed cause, and the only carrier that distinguishes "the linter reported an error" from "the linter never ran" without matching a rule-id string.

Sound. One acknowledged cost: counts.errors now includes a non-lint event; acceptable, since the rule id and lintError disambiguate and a separate count would widen the counts shape.

lintError optional — right design, wrong stated reason. Right on its own merits: (i) generationError?: string on the same report's case result is already the present-when-set shape, so lintError? matches the idiom beside it; (ii) a required field would force unscorableScore() to pick a value for a case whose linter never ran for an upstream reason — undefined there would assert "ran clean", which is false; absent is the honest value; (iii) the docblock's "absent means it ran" is the semantics. The PR's stated reason — that a required field would have forced an edit into a file another card is fenced to — is not a reason a published type should take a shape; had required been right, the fence would have had to yield. It did not have to, because optional is right anyway. Recorded; no change requested.

Scope fence — leaving the crash to #15880 is right

On stronger grounds than the one stated. The scorer's contract is for any throw from any rule, and the test pins it through a mocked linter, so this PR's guarantee does not depend on #15880's fate; the crash's repair is a product/contract choice (guard on typeof label === 'string', or resolve the default-locale entry — and the objects[].label vs apps[].label asymmetry) that the issue correctly routes to triage; and no user is left worse off — os lint already exited 1 on the input before this PR, and the eval face now agrees with it. "Repairing it would delete the input that proves reachability" is the weakest of the three reasons (the suite does not rely on that input). Not a blocker.

Measurements (exit codes captured before any pipe; worktree at this head, git status clean)

Resolution path, stated: the unit probe and the tests reach score.ts through source; the wire runs reach it through a dist built from this head (JS-only, OS_SKIP_DTS=1, lint-command closure of 16 packages plus @objectstack/cli). That partial build leaves oclif ModuleLoadError warnings on stderr for unrelated commands (cloud:*, data:*, …); none for lint, and stdout is well-formed JSON.

NOT MEASURED (neither pass nor red): the mutation sweep's counts; the dev's ablation (6 RED / 25 GREEN prediction) — not re-run; the wire-level before row (derived from the OLD scorer's output and the unchanged passed/exit logic, not driven); pnpm lint and pnpm typecheck locally — not re-run (CI's TypeScript Type Check is green at this head; the local cli build ran --noCheck); DTS emission — skipped in the local build.

Non-blocking notes

• The PR body cites the ADR-0087 gate as confirming non-breaking-ness; that gate cannot confirm it (blind to omission by design). The reasoning above is what carries the ruling; the outcome is unchanged.
• An Error('') thrown by a rule yields lintError: "", which a truthiness-reading consumer would miss; the other two carriers still hold. Exotic; not worth a change.

Generated by Claude Code